一、先讲背景
git分支主要有以下:
主分支:master,保证所有已发布到生产环境的分支都已merge到master,并且,新分支比如从master创建
日常分支:daily,本地开发和测试环境使用,保证所有的已上生产和发布测试的分支都已merge到daily
其他分支:版本分支或bug分支,从master拉取,并在merge到master后删除
前端团队采用如下开发流程:
(接到版本需求后,假设不需要后端接口配合,或后端接口已开发完毕)
二、开发阶段
第一阶段(本地开发+测试环境阶段)
step1:master创建一个新分支featrue-2019-2,此为版本分支,并拉取到本地,使用SwicthHosts将本地开发环境映射到日常环境,也称测试环境,在本地开发调试
step2:本地开发后,使用sourcetree保存并提交到远程featrue-2019-2分支,你使用git命令也是一样
step3:拉取日常环境分支daily,并将featrue-2019-2 merge到 daily
step4:使用JenKins(日常环境账号)登录后构建daily分支,表示对daily的代码执行npm run
build+push,构建成功后通知测试人员 step5:若测试有问题,修改后,重复step2、step3、step4,直到测试通过
第二阶段(预发阶段)
step1:merge master 到 featrue-2019-2,保证featrue-2019-2已包含所有的生产代码
step2:使用JenKins(预发环境账号)登录后构建featrue-2019-2分支,构建成功后通知测试
step3:若测试有问题,检查测试环境是否也有此问题,若有,则要返回第一阶段的step2
第三阶段(生产阶段)
step1:此分支发预发后,若有别的分支发了生产,则需要执行merge master 到
featrue-2019-2,保证featrue-2019-2已包含所有的生产代码
step2:使用JenKins(生产环境账号)登录后构建featrue-2019-2分支,构建成功后通知测试
step3:featrue-2019-2 merge 到 master,并删除featrue-2019-2,
step4:若测试有问题,汇总问题,从master拉取bug分支,例如可命名为featrue-2019-2-bug,从第一阶段开始,开启一个新的版本开发
三、分支原则
1、保证master分支是唯一主分支
2、所有版本分支,所有需求,所有代码,必须按“照构建日常——>构建预发——>构建生产”的顺序执行
3、所有版本分支只开发此版本相关内容,不可混合其他版本需求开发
4、分支发布生产后,必须尽快merge到master
5、分支的生命周期,从master上拉取开始,到merge到master以后结束,一个分支尽量只使用一次,即merge到master以后就删除
6、不要频繁发布生产,日常和预发不受限制
四、预发环境的必要性
以前的公司,只有测试/预发环境和正式/生产环境,来到这家公司后,才了解到预发环境的必要性。
测试环境,用来测试代码没有问题,但是测试环境里都是测试数据,和真实数据差别很大,大家都知道,对于前端来说这些数据的不同会造成特殊情况存在,例如测试环境的数据不合法。
而预发环境则是真实数据,基本上用户在预发环境的所见,99%等同于在生产环境的所见,所以,必要性可想而知。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。